⚠️ AI-generated review. Produced by an automated agent and posted from this account — not written by hand. Findings below are leads to verify, not confirmed conclusions.

This PR replaces ChaCha20 expansion with direct duplex squeezes in the Fiat-Shamir transcript, buffering 4 candidates per squeeze. The core change holds up: the sponge already yields uniform bytes, the rejection bound is unchanged, and the Keccak call count stays flat (3025 → 3025), so the ~1.6M cycles are pure ChaCha removal; FS ordering is preserved at the FRI commit loop, grinding seed and query-index call sites, and next_sample_u64's slice is guarded by out_pos + 8 > SQUEEZE_LEN, so no new panic path is introduced. The open issues are test coverage and the benchmark record.

crypto/crypto/src/fiat_shamir/default_transcript.rs:117 — the absorb-invalidation is the only new soundness-critical line in this PR and no test covers it. crypto/stark/src/fri/mod.rs:90 samples ζₖ (leaving buffered bytes), line 106 absorbs rootₖ, then the loop samples ζₖ₊₁; delete self.out_pos = SQUEEZE_LEN; from append_bytes/append_field_element and ζₖ₊₁'s leading coordinate comes from the pre-root squeeze — the prover knows part of the next FRI challenge before committing the layer. Every test in default_transcript_tests.rs still passes with those lines removed (they either use raw sample() only, or absorb while the buffer is already empty), as does the whole prove→verify suite and the FRI replay at crypto/stark/src/tests/fri_tests.rs:208: prover and verifier consume the same stale bytes in lockstep, so "190 roundtrips pass" is precisely the check that cannot see this. Missing test: two transcripts each sample_field_element() (leaving buffered bytes), one then append_bytes(b"x"), assert the next sample_field_element() differs — same for append_field_element and for an interleaved raw sample().

crypto/crypto/tests/transcript_snapshot.rs:24 — the Clone-snapshot test that the GPU fallback contract depends on is blind to the newly added state. It snapshots right after append_bytes(b"prelude"), so out_pos == SQUEEZE_LEN at that point, and it compares only state(), which is hasher.clone().finalize() and never observes out_buf/out_pos; a Clone that dropped the buffer passes it unchanged. The real snapshot is taken mid-buffer: γ is sampled at prover.rs:1475 (3 coords, 8 bytes left over) and nothing is absorbed before try_fri_commit_gpu's transcript.clone() at gpu_lde.rs:1835, so the first post-snapshot operation consumes the leftovers. A lossy restore would have the CPU fallback squeeze fresh bytes for ζ₀ while the verifier consumes the leftovers — a rejected proof appearing only on the GPU-failure path. Take the snapshot immediately after a sample_field_element() with no absorb after it, and assert the restored transcript replays identical subsequent sampled values instead of comparing state().

Bench record — the last /bench here is red: 30.840s → 38.056s (+23.4%), 57086 MB → 72987 MB (+27.9%), low variance. This diff cannot produce that: the prover does a few thousand samples per proof, each now strictly cheaper and allocation-free, and the struct grows by 40 bytes of stack — there is no mechanism for 15.9 GB of heap. It reads as a baseline artifact problem: benchmark-pr.yml's "Download baseline artifact" step takes the newest successful main-push run rather than one pinned to this branch's merge-base, and e9e7b24e had just merged #832/#847/#843/#844/#845 in. The head also moved to 2d2aeaaf while the run was in flight, so the recorded number is not even for the current head. Rerun on 2d2aeaaf against a fresh main baseline and close the flag out — a proof-breaking transcript fork shouldn't land with an unexplained 23%/28% prover regression as its last recorded result.

crypto/crypto/src/fiat_shamir/default_transcript.rs:26 — the −3.75% was measured at blowup 2 with 1 query. The removed work scales with the number of field-element challenges (β, z, γ, per-layer ζ); query-index sampling never touched ChaCha, so the ~1.6M absolute stays roughly constant while total guest cycles grow with query count. At the real inner setting (~219 queries) that headline drops to well under 1%. #846 landed the real-query-count recursion bench and is already merged into this branch — rerun there and quote the absolute per-proof saving. Relatedly, the doc comment and PR body put ChaCha at "~2–3M guest instructions/proof" while the measured total delta (which also includes whatever the buffer saves on squeezes) is 1.63M, so that figure should come down to what was actually measured.

Nits:

• crypto/crypto/src/fiat_shamir/is_transcript.rs:12 — "the inner state of the transcript that fully determines its outputs" is no longer true: a transcript refilled via next_sample_u64 and one that did a raw sample() have byte-identical hasher chains and identical state() but different next challenges; both current callers (grinding seed, prover.rs:1546 / verifier.rs:1497) sit at protocol-synchronized points so it is safe today, but the contract should be reworded so state() is not treated as a full transcript position.
• crypto/math/Cargo.toml:18 — rand is dead in math after this trait change (no reference survives in crypto/math/src, only benches/goldilocks_benchmark.rs, which the existing dev-dependency covers) yet remains a mandatory dep in every consumer's graph including the guest, the opposite of the PR's stated goal; same for crypto's own rand/rand_chacha dev-deps at Cargo.toml:34-35, which nothing in that crate references now.
• crypto/math/src/field/extensions_goldilocks.rs:575 — the per-coordinate loop is a verbatim copy of GoldilocksField::sample_field_element_from and FpE is exactly its return type; &mut closure implements FnMut, so three delegated calls produce the identical candidate stream and keep the rejection bound in one place.
• crypto/crypto/src/tests/default_transcript_tests.rs:11 — basic_challenge pins bytes only for raw sample(), whose semantics didn't change; a known-answer test pinning the first ext3 element and a sample_u64 sequence crossing the refill boundary would be cheap insurance against later drift on the compatibility surface this PR breaks.